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ABSTRACT 


The  U.S.  Army  uses  a  Unit  Readiness  Index  to  track  the  combat  readiness  of 
systems.  The  Unit  Readiness  Index  relies  on  the  accuracy  of  automated  and  manual 
testing  of  the  hardware  and  related  software  of  the  Line  Replaceable  Units  (LRUs)  that 
comprise  the  system.  These  tests  are  based  on  a  GO/NOGO  scenario.  When  an  LRU 
fails,  vehicle  commanders,  and  commanders  up  the  chain  of  command,  can  override  this 
and  continue  with  a  mission.  Overriding  the  NOGO  recommendations  produces  a  false 
combat  readiness  status  for  the  unit,  and  creates  a  number  of  problems  related  to  unit 
combat  decisions  as  well  as  logistical  support.  This  thesis  introduces  a  new  process  for 
more  effectively  tracking  combat  readiness.  It  outlines  some  of  the  problems  associated 
with  the  current  GO/NOGO  scenario  and  examines  the  current  tests,  artifacts  and  data 
available  from  the  current  process.  It  proposes  an  additional  Report  process  and  shows 
how  this  new  process  will  eliminate  the  readiness  tracking  problems  associated  with  the 
GO/NOGO  scenario.  It  also  presents  the  design  of  a  Vehicle  Database  and  Master  Fault 
Database  to  support  the  proposed  process,  and  presents  several  sample  reports  generated 
from  this  Master  Fault  Database. 
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I.  INTRODUCTION 


A.  DESCRIPTION  OF  PROBLEM 

The  Army  uses  the  Unit  Readiness  Index  (URI),  described  in  detail  in  Chapter  II, 
to  evaluate  combat  readiness.  To  make  this  thesis  manageable,  we  shall  focus  our 
discussion  on  a  single  platform,  the  Abrams  M1A2  Main  Battle  Tank,  although  the  URI 
applies  across  all  platforms. 

For  the  Abrams  M1A2  Main  Battle  Tank,  the  hardware  portion  of  each  Line 
Replaceable  Unit  (LRU)  undergoes  a  continuous  automated  self-test  (ST).  When 
hardware  fails,  crewmembers  normally  perfonn  an  intrusive  Built-In  Test  (BIT). 
Continued  failure  results  in  having  the  hardware  undergo  an  even  more  rigorous  Fault 
Isolation  Test  (FIT).  The  software  for  all  three  sets  of  tests  resides  in  each  LRU. 

The  Army  uses  the  phrase  “hardware”  to  describe  an  LRU;  in  reality,  an  LRU 
consists  of  a  hardware  component  and  a  corresponding  software  component.  If  an  LRU 
fails,  no  differentiation  is  made  between  the  two  components.  A  failed  LRU  affects  the 
readiness  of  the  vehicle,  which  in  turn  affects  the  readiness  of  the  vehicle’s  unit.  A  tank 
out  of  commission  affects  readiness  up  the  chain  of  command  through  the  Division  level. 
Figure  1  depicts  a  typical  tank  command  structure.  Figure  2  shows  the  LRUs  contained  in 
the  M1A2  (Ronald  Siegel  1999).  Not  all  LRUs  have  software  resident  within  them; 
Figure  3  depicts  the  architecture  for  the  LRU  components  in  a  tank  that  contain  software 
(GDLSM1A2  SDP  2003). 

Test  results  of  an  LRU  are  classified  as  either  GO  or  NOGO.  When  it  is  NOGO, 
the  LRU  must  be  replaced,  or  the  entire  vehicle  is  considered  NOGO.  A  potential  major 
problem  is  created  when  test  results  are  overridden  and  failures  are  not  addressed.  A 
vehicle’s  commander  can  override  the  test  results,  which  typically  occurs  when  the 
failure  is  examined  and  determined  to  be  in  a  non-tnission  critical  area.  Reported  failures 
can  also  be  overridden  up  the  chain  of  command  at  the  Company  or  Battalion  level.  A 
vehicle  declared  out  of  commission  affects  the  operational  readiness  of  both  the  unit  and 
the  commands  of  which  the  unit  is  a  member. 
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Figure  1  Tank  Command  Structure 


M1A2  LRU  Architecture 
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Figure  2  M1A2  LRU  Architecture 
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TEU  CID  RIU 


Figure  3  M1A2  Software  Architecture 


There  are  many  good  reasons  for  overriding  failures.  For  example,  during  several 
conversations  with  former  Tankers,  they  all  stated  they  would  not  want  to  take  the  time  to 
enter  infonnation  on  failures  while  they  were  in  Combat  Mode.  Overriding  a  failure 
should  only  delay  responding  to  the  failed  test.  Overriding  a  readiness  rating  on  a  piece 
of  hardware,  for  any  reason,  has  numerous  ramifications,  as  described  in  the  following 
paragraphs: 

Invalid  Test.  If  the  same  test  is  failing  across  multiple  units,  the  test  may  be  bad. 
Not  reporting  it  will  increase  the  likelihood  it  will  never  get  corrected.  Furthermore, 
ignoring  a  NOGO  because  the  crew  thinks  the  test  may  be  reporting  an  invalid  failure 
may  result  in  the  tank  crew  failing  to  identify  a  real  problem.  This  might  occur  when  the 
crew  learns  the  same  test  is  failing  in  other  vehicles.  While  it  may  be  invalid  in  some 
vehicles,  it  might  indeed  be  valid  in  others. 

Common  Problem.  If  the  same  test  is  failing  across  multiple  units  and  the  test  is 
not  bad,  then  a  common  problem  exists  and  needs  to  be  addressed.  The  bad 
hardware/software  needs  to  be  resolved  as  soon  as  possible. 
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Number  of  Failed  LRUs.  If  only  a  few  LRU  failures  are  reported,  the  problem 
may  not  get  resolved.  When  there  are  large  numbers  of  failures  for  the  same  test,  the 
reason  behind  the  failures  needs  to  be  quickly  detennined  and  resolved.  Overriding 
failures  can  mask  the  magnitude  of  the  problem.  Resources  may  be  directed  toward  other 
more  widely  reported  problems  instead  of  the  larger  ‘hidden’  one. 

Undefined  Actual  Operational  Readiness.  If  the  Tank  Commander  (TC) 
overrides  the  test,  or  those  above  the  TC  in  the  chain  of  command  override  the  failure 
report,  a  vehicle  may  be  rated  as  combat  ready  when  a  potentially  serious  problem  is 
aboard.  The  Tank- Automotive  Armament  Command  (TACOM)  Commanding  General, 
MG  N.  Ross  Thompson  III  gave  a  briefing  discussing  the  state  of  readiness  in  vehicles 
entering  Iraq  to  the  Chief,  Logistics,  Coalition  Forces  Land  Component  Command,  MG 
Claude  V.  Christianson.  During  this  briefing,  MG  Thompson  estimated  that  “FORSCOM 
IG  unit  maintenance  brief  findings  state  reported  readiness  rates  exceeding  90%  while 
actual  readiness  [was]  at  less  than  50%”(MG  Thompson  2003). 

Logistics.  The  supply  of  spares  on  hand  might  need  to  be  increased,  but  problems 
aren’t  being  identified  in  the  supply  chain.  When  there  are  multiple  vehicles  requiring  a 
replacement  LRU  and  the  problem  is  not  recognized  because  the  overridden  failures  are 
not  reported,  there  won’t  be  enough  spares  to  satisfy  this  need. 

Additional  Failures.  Continuously  overlooking  a  failure  may  impact  or  mask 
other  problems  developing  in  the  same  piece  of  hardware.  This  may  cause  the  developing 
problem  to  be  overlooked,  thus  creating  a  potential  hazardous  situation  and  jeopardizing 
the  actual  readiness  of  the  unit. 

Trend  Analysis.  Failed  LRUs  should  undergo  trend  analysis  to  determine  if 
failures  are  occurring  after  a  period  of  time  or  usage,  or  if  multiple  problems  are 
developing  in  the  same  area.  Not  reporting  failures  prevents  this  type  of  analysis.  Trend 
analysis  for  software  issues  can  indicate  whether  the  software  is  too  complicated  or  has 
had  too  many  modifications  applied.  This  information  is  important  to  the  group 
maintaining  the  software  and  is  used  for  decisions  such  as  whether  the  software  should  be 
repaired  or  needs  to  be  replaced. 


4 


B.  PROPOSED  SOLUTION 

Commanders  will  continue  to  have  the  capability  to  override  test  results  during 
combat  situations.  This  capability  will  continue  to  be  available  up  the  chain  of  command. 
However,  failures  cannot  be  overlooked;  the  ramifications  are  too  serious.  A  simple 
solution  is  to  modify  the  test  software  so  that,  when  not  in  combat  mode,  each  failure 
requires  a  comment.  Test  results  for  all  failures,  with  accompanied  comments,  will  be 
stored  in  a  vehicle  database.  At  a  later  time,  while  undergoing  routine  preventive 
maintenance,  test  results  will  be  included  as  part  of  the  hardware  readiness  report 
submitted  by  the  maintenance  facility.  They  will  also  be  merged  into  a  Master  Fault 
database  residing  at  each  level  of  command  above  the  vehicle,  along  with  any  comments 
or  explanations  for  overriding  vehicle(s)  readiness  status  by  the  higher  command. 

This  information  will  be  used  to  perform  trend  analysis  at  the  vehicle’s  major 
command  and  provide  commanders  with  an  accurate  understanding  of  the  actual 
readiness  of  the  vehicles  under  that  command. 

C.  THESIS  ORGANIZATION 

This  chapter  gives  a  brief  description  of  the  problem,  providing  an  accurate 
picture  of  the  operational  readiness  of  vehicles  within  a  major  command,  and  then  offers 
a  solution  to  this  problem.  Chapter  II  presents  an  analysis  of  the  current  Unit  Readiness 
Index  tracking  process.  It  explains  the  tests  that  are  used  to  detennine  the  readiness  of  a 
vehicle  and  gives  examples  of  reports  currently  generated  from  this  data.  The  chapter 
also  performs  a  high-level  use  case  analysis  of  the  proposed  enhancement  offered  in 
Chapter  I. 

Chapter  III  contains  elements  of  a  design  for  a  Master  Fault  Database,  which  is 
part  of  the  proposed  problem  resolution.  The  design  includes  Object  diagram;  sample 
database  layouts;  and  closes  with  several  sample  reports  generated  using  the  database. 
Chapter  IV  is  the  thesis’  conclusion.  It  discusses  the  value  added  by  the  proposed 
enhancement  as  well  as  challenges  and  opportunities  associated  with  the  implementation 
of  this  solution. 
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II.  ANALYSIS  OF  THE  UNIT  READINESS  INDEX  TRACKING 

PROCESS 


A.  UNIT  READINESS  INDEX 

The  Army  currently  uses  a  Unit  Readiness  Index  to  detennine  the  state  of 
readiness  of  units  of  all  sizes.  Units  may  vary  from  a  squad  of  tanks,  for  example,  all  the 
way  to  a  brigade  or  higher.  Information  is  extracted  from  the  “Army’s  unit  status  report 
(USR),  which  is  a  part  of  the  Global  Status  of  Resources  and  Training  System 
(GSORTS).  GSORTS  is  an  internal  management  tool  for  use  by  the  Chainnan,  Joint 
Chiefs  of  Staff  (CJCS),  the  Joint  Staff,  the  Services,  the  unified  commands,  and  the 
combat  support  agencies.  GSORTS  is  the  single  automated  reporting  system  within  the 
Department  of  Defense  that  is  the  central  registry  of  all  operational  units  of  the  U.S. 
Anned  Forces  and  certain  foreign  organizations.  As  a  unit  readiness  system,  GSORTS 
indicates  the  level  of  selected  resources  and  training  required  to  undertake  the  mission(s) 
for  which  a  unit  was  organized  or  designed.  GSORTS  provides  this  information  on 
measured  units  at  a  specific  point  in  time.”  (U.S.  Army  2001) 

Three  resource  areas  are  examined:  personnel,  including  the  personnel’s  training 
status,  equipment-on-hand,  and  equipment  serviceability,  using  the  criteria  provided  in 
regulation  220-1.  Each  unit  commander  also  determines  an  overall  unit  status  level  by 
considering  the  status  of  the  unit’s  measured  resource  areas  and  training  status  and  by 
applying  his  professional  judgment.  This  information,  including  remarks  submitted  to 
clarify  category  levels,  is  gathered  together  to  create  a  Mission  Accomplishment  Estimate 
(MAE).  The  MAE  is  the  reporting  unit  commander’s  subjective  assessment  of  the  unit’s 
ability  to  execute  that  portion  of  the  wartime  mission  that  it  would  be  expected  to 
perform  if  alerted/committed  within  72  hours  of  the  “as-of’  date  of  the  report.  The 
commander  expresses  this  estimate  in  terms  of  the  percentage  of  the  wartime  mission  that 
the  unit  could  accomplish  if  it  were  alerted/committed. 

The  infonnation  is  gathered  via  the  Personal  Computer/ Army  Status  of  Resources 
and  Training  System  (PC/ASORTS),  whenever  possible,  or  is  submitted  via  DA  Form 
2715.  Reports  are  submitted  as  of  the  15th  day  of  each  month  and  must  be  received 
within  96  hours  of  the  due  date. 
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The  “National  Security  and  Military  Strategies  require  the  Anny  to  provide  forces 
capable  of  world-wide  operations  across  the  full  spectrum  of  conflict,  from  small 
peacetime  engagements  to  major  regional  wars.  In  order  to  meet  these  readiness 
challenges,  we  must  resource  the  Anny  with  quality  people,  lead  by  competent  and 
confident  leaders,  and  armed  with  reliable,  modem  equipment.”  (DAVID  L  GRANGE, 
MG  1997)  Thus,  we  need  to  know  the  following: 

•  How  can  we  detennine  what  our  state  of  readiness  actually  is? 

•  If  the  state  is  too  low,  what  specified  minimal  level  should  that  state  be 
raised  to? 

•  What  will  it  take  to  raise  it  to  that  level? 

•  How  accurate  is  this  assessment? 

Units  determine  and  report  in  the  Unit  Status  Report  (USR)  an  equipment 
serviceability  (ES)  level  (R-level)  (See  Table  1,  extracted  from  Table  6-1  in  AR220-1.). 
The  unit’s  R-level  indicates  how  well  the  unit  is  maintaining  its  on-hand  equipment. 


Level 

Equipment  other  than  aircraft 

Aircraft 

1 

100-90% 

100-75% 

2 

89-70% 

74-60% 

3 

69-60% 

59-50% 

4 

Less  than  60% 

Less  than  50% 

Table  1  Level  for  percentage  of  equipment  fully  mission  capable 


Once  a  measurement  of  the  overall  state  of  equipment  is  determined,  decisions 
can  be  made  as  to  what  actions  should  be  taken  to  raise  a  substandard  level  of  readiness 
to  an  acceptable  level.  For  example,  a  cost  tradeoff  analysis  may  be  made  to  detennine  if 
the  hardware  should  be  improved,  if  software  modifications  should  be  made,  or  if  some 
combination  of  the  two  must  be  performed. 
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There  are  three  levels  of  testing  performed  on  the  M1A2.  These  are  described  in 
Table  2  and  are  extracted  from  the  Fault  Management  volume  of  the  M1A2 
System/Segment  Design  Document  (GDLS  S/SDD  2003). 


Self -Test  (ST) 

Self-Test  is  the  first  level  of  embedded  diagnostics  within  the 

M1A2  tank.  ST  reports  faults  to  the  crew  during  all  modes  of 

operation.  Self-Test  data  runs  in  the  background  of  each 

LRU.  ST  runs  upon  power-up  and  performs  a  health  check 

on  the  system  without  affecting  tank  functions. 

Built-In-Test  (BIT) 

Built-In-Test  is  the  second  level  of  embedded  diagnostics. 

BIT  is  an  intrusive  test  of  the  system  health  status. 

Fault-Isolation-Test  (FIT) 

Fault  Isolation  Test  is  the  third  level  of  embedded 

diagnostics.  FIT  utilizes  the  results  from  Self-Test  and  Built- 

In-Test  to  reduce  ambiguity  groups  within  the  system.  The 

corresponding  ST  and  BIT  results  are  incorporated  into 

variables.  These  variables  make  up  several  hundred  Boolean 

equations  to  isolate  faulty  units  and  generate  troubleshooting 

procedure  (TP)  numbers. 

Table  2  Levels  of  Software  Testing 


1.  Self-Test 

Self-Test  (ST)  runs  continuously  in  all  modes,  and  is  the  first  level  of  diagnostics 
to  detect  a  failure.  Upon  detection  of  a  failure,  a  NOGO  message  is  displayed  on  the 
Commander’s  Integrated  Display  (CID),  with  a  backup  copy  of  the  message  displayed  on 
the  Gunner’s  Control  and  Display  Panel  (GCDP).  The  message  identifies  the  LRU 
containing  the  failure,  i.e.,  if  a  failure  is  detected  in  the  DID  LRU,  the  NOGO  displayed 
is  for  that  LRU. 
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2.  Built-In-Test 

Once  ST  detects  a  failure,  the  tank  crew  is  expected  to  perform  further  diagnostic 
testing  using  Built-in  Test.  Figure  4  is  a  screen  shot  showing  the  status  of  the  LRUs  in  the 
M1A2,  following  BIT. 

This  testing  can  only  be  perfonned  while  in  Diagnostics  mode  -  if  the  vehicle  is 
in  Combat  or  some  other  mode,  testing  must  be  delayed  (due  to  the  intrusive  level  of  the 
BIT  testing.)  Once  in  Diagnostics  mode,  BIT  is  executed  to  confirm  the  failure.  BIT  is 
more  stringent;  for  an  LRU,  according  to  paragraph  1.1.3  of  the  S/SDD  (GDLS  S/SDD 
2003); 

“The  BIT  diagnostics  augmented  by  Manual  Test  Procedure  (MTP),  shall  meet 

the  following  requirements: 

a.  Ninety-five  percent  probability  of  detecting  all  on-board  system-level 
faults. 

b.  Zero  ambiguity  in  fault  isolation  of  a  system. 

c.  Ninety-percent  probabilities  of  fault  isolating  to  a  LRU  or  Line 
Replaceable  Module  (LRM). 

d.  Less  than  TEN  PERCENT  BIT  false  alarm  rate. 

e.  BIT  failure  shall  not  degrade  performance  of  the  prime  system  (i.e., 
BIT  failure  is  transparent  to  systems  operation). 

f.  BIT  shall  have  self-test  capability.” 

When  ST  or  BIT  detects  fault  conditions  that  cannot  be  resolved  or  explained,  the 
problem,  including  a  description  of  the  extent  of  the  failure  and  a  recommended  severity 
level,  is  submitted  to  organizational  maintenance. 
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Figure  4  BIT  Vehicle  Test  Results 


3.  Fault-Isolation-Test 

After  verifying  the  problem  is  reproducible  (by  re-running  BIT),  maintenance 
personnel  will  run  the  Fault-Isolation-Test  using  a  Direct  Support  Electrical  System  Test 
Set  (DSESTS),  shown  on  the  left  in  Figure  5  below. 


P2  to  GPIA  UJ6  P5  (Not  Used) 


Figure  5  DSESTS,  connected  to  a  DID 

If  FIT  also  fails,  the  maintenance  unit  will  replace  the  faulty  Line  Replaceable 

Unit  (LRU)  hardware.  When  the  maintenance  unit  detennines  the  problem  exists  in 
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multiple  LRUs  they  will  declare  that  an  LRU  ambiguity  group  exists.  (If  the  failure 
cannot  be  isolated  using  these  tests,  the  maintenance  personnel  will  perfonn  manual 
testing  to  try  to  identify  the  problem.) 

Unit  maintenance  will  perform  further  testing  using  the  Intermediate  Forward 
Test  Equipment/Commercial  Equivalent  Equipment  (IFTE/CEE).  An  LRU  typically 
consists  of  one  or  more  Shop-Replaceable  Units  (SRUs).  An  example  of  an  SRU  would 
be  a  circuit  board  contained  in  an  LRU  (See  Figure  6,  below)  or  the  1553B  cable 
connecting  the  LRU  to  the  network.  The  IFTE/CEE  tests  to  the  sub-SRU  level;  i.e.,  it 
examines  the  components  on  a  circuit  board.  Figure  7  lists  actual  LRUs  and  embedded 
electronic  module  SRUs  for  an  M1A2. 


itNimniunnu  ..Vjjjmuiiimniiinimi 


Figure  6  Driver’s  Integrated  Display  -  Internal  View 
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Figure  7  M1A2  LRUs  and  Electronic  Module  SRUs 
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When  a  failure  occurs  and  a  FIT  warning  is  displayed,  the  Tank  Commander  or 
Maintenance  crewmember  can  display  the  corresponding  troubleshooting  procedure  (TP) 
number.  Figure  8  is  a  screen  shot,  showing  TP  #s  generated  during  FIT.  Each  TP 
number  is  unique  and  uses  the  results  from  Self-Test  and  Built-In-Test  to  reduce 
ambiguity  groups  within  the  system.  The  corresponding  ST  and  BIT  results  are 
incorporated  into  variables.  These  variables  make  up  several  hundred  Boolean  equations 
to  isolate  faulty  units  and  generate  troubleshooting  procedure  (TP)  numbers.  For 
example, 

“TP#  302  will  be  generated  if  the  [remote  power  control]  RPC  on  the  [Hull  Power 
Distribution  Unit]  HPDU  that  supplies  power  to  DID  is  TRIPPED  or  NO-LOAD.  At  the 
same  time,  1553  data  bus  communication  must  be  valid  to  DID.  TP#  302  is  represented 
by  the  following  equation. 

lv  =  (  AM_HPDU_RPC_8_TRIP_DID  or  AN_HPDU_RPC_8_NO_LOAD_DID 
)  and  IU_D  AT  ABU  SADID  and  IVDATABUSBDID” 

A  detailed  set  of  formulae  used  for  determining  these  troubleshooting  procedures 
are  contained  in  the  M1A2  System/Segment  Design  Document.  (GDLS  S/SDD  2003) 


Figure  8  Sample  FIT  TP  #s 
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B.  EXISTING  REPORTS 

Data  is  generated  at  the  unit  level  and  gathered  by  the  Anny  Material  Status 
System  where  it  is  stored  in  the  Readiness  Integrated  Data  Base  (RIDB).  The  RIDB  is 
used  for  analysis  of  readiness  data  generated  from  unit  status,  aircraft,  missile,  and 
ground  equipment  reporting.  Two  reports  are  issued  using  data  within  the  RIDB: 
Operational  Readiness  Summary  Reports,  which  show  the  Operational  Readiness  status 
within  the  Major  Command  at  the  date  the  report  is  generated,  and  the  Equipment 
Downtime  Analyzer  Report,  which  shows  more  detailed  information  for  the  date  the 
report  is  generated.  Both  reports  only  go  to  a  vehicle  level  of  detail.  Failure  information 
on  LRUs,  while  reported  by  the  Unit,  is  not  covered  by  either  of  the  two  reports. 

1.  Operational  Readiness  Summary  Reports 

Figure  9  shows  four  actual  examples  of  the  summary  reports  of  the  operational 
readiness  for  one  of  the  fielded  M1A2  Divisions.  They  explain  why  the  Operational 
Readiness  goal  of  90%  wasn’t  met,  and  what  actions  are  being  taken  to  resolve  it.  Each 
report  reviews  the  Fully  Mission  Capable  (FMC)  Index  for  the  reporting  period.  There 
are  several  issues  to  highlight: 

The  FMC  Index  is  an  average  value  for  the  appropriate  monthly  period.  It  does 
not  address  figures  for  any  specific  day.  The  daily  Index  may  be  much  higher  (or  lower) 
than  the  monthly  value.  Moreover,  units  being  deployed  are  not  included  in  the  reports 
and  the  reports  consistently  recommend  the  same  near-term  fixes. 
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Monthly  Backup  Information 

Momhly  Backup  Information 

MIA-  Abram*  lank 

MIA2  Abrams  Im* 

FMC  at  ot  1 5  Nov  11)  Mkl% 

FMC  as  of  1 5  Feb  04  M0.4’S> 

r>: asons  win  rrn:  mi  s;  did  not  mi  i  i  com  ; 

RE  ASONS  WHY  THE  Ml  A2  DID  NOT  MEET  COAL: 

1.  Ihe  KIM)  Alla  !•<  the  •-!  Mil  .1  •-!  ..  ••  Vil',  II'-  •.liiiw  .  Jit 

1 .  Ihc  K1  DU  Oulu  lot  the  period  ending  1 3  Feb  04  shuws  ail  M 1 A2 

M 2 A2  CMC of  86. 1%  u ith  3KS  vehicle*  reported.  The 

FMC  of  NO .4%  with  uiiiy  172  vehicles  repuned  Lost  muiith  443 

dimity  at  ICAV  i*  short  15^  vehicles  from  IjkI  report  period. 

vehicles  wen  reported.  The  ICAV  did  not  report  during 

flic  mif.r  unite  that  failed  the  DA  goal  for  Ml  A2  mv  listed 

deployment  to  SWA.  and  3ACR  did  not  report  during  Redeploy 

in  Ok  matrix  below 

t.MI  OTA  KMC  NMCS  NMCM 

The  4th  ID  and  Ft  Knox  art  the  only  unite  that  retorted  M 1  A2s  fur 
FetotM 

3  ACR  124  *2%  14%  4% 

UNIT  orv  FAR  NMCS  NMCM 

4  ID  124  81%  16%  3% 

J  :  i  U  R  c idii  e  i  Im  in'  mdh  1 

Ft.  Knox  50  72%  12%  16% 

4  ID  122  84%  10%  6% 

FMC  rrom  77%  tu  82%.  like  5  AI  R  ixMinua  ta  *<c  high 

2.  Ft.  Knox  lie  readmes*  at  Ft.  Knox  decreased  hum  Kfi%  to 

OPTEMPO  during  deployment  to  OIF  Suspension  pait* 

Ml  1 1  Knot  is  i  IT  \DOC  unit  with  a  low  Force  Activity 

continue  to  he  tmpn-iaJ  by  the  terrain  m  theater  Part*  an 

Designation  tFADl  Requirement*  for  Deploying  Redeploying 

(lowing  into  the  ate  t.  touting  tm  improvcmaM  in  readiness 

unit*  receive  higher  pnonev.  Ilighcipll-.MPO.  fleet  age.  and 
peneanel  availability  ate  all  atlccting  the  unit's  ability  to  mainuni 

3.  4th  Itiiai  -t  r  ■-  -•i.iiii .  a. 

the  4th  ID  increased  by  5%  FMC  from  76%to8|%  FMC 

ndlnai. 

The  4th  ID  is  deployed  to  OIF  and  i»  seeing  high  OPTEMPO 

1  4rh  Infantry  Dr  '  ying  Ihe  read  remain 

Suspension  parti  continue  to  be  impacted  by  the  terrain  in 

'  •  ID  only  shopped  sligli '  1  Ml  Um4ID 

thcatet .  Part*  are  flowing  into  thcaaet .  causing  m 

u  in  the  process  of  redeployment.  Ihe  vehicles  are  being  prepaied 

improvement  in  readiness. 

lur  transpuruLRin  tuck,  tu  home  siatrcn  ot  depot  fur  repair.  Ihe 
ropatsiliotu.  fur  4ID  in-theulcr  are  ill  the  process  of  being 

IO  MMNFANFMI  SN(  I  MIM  At  1  1*  iN' 

cancelled. 

Near  -  Term  Fixes: 

-  lUud  Wheel  and  Arm  assemblies  NMCS  boikuedm 

READINESS  ENHANCEMENT  ACTIONS: 

filled  in  DccO.V 

Nmi  -  Term  fixrr 

Interne  management  and  focused  distribution  of  critxal 

-  Intense  Management  of  NMCS  rvquislions 

supply  item* 

•  JAP  available  to  rill  fix  Abrams  unique  parts  m  SWA. 

-  Disassembly  programs  in  place  to  obtain  critical  parts. 

-  Disassembly  progj  am*  in  place  tu  obtain  critical  purl*. 

Extended  Fixes. 

-  Ramped  up  delnvric*  cm  critical  assemblies 

Extended  Fixe* 

-  Improve  distribution  system  in  theater 

-  Ramped  up  deliveries  cm  critical  assemblies 

-  KIM.  1  vehicles  to  10  20  standard*.  program  intended 

-  RESET  vehicle*  to  l(k’20  standard* 

Monthly  Backup  Information 

Monthly  Backup  Information 

MIA2  Abrams  Tank 

MIA2  Abrams  I  an* 

KMC  a*  of  1 5  Apr  04  86.K% 

FMC  as  of  13  Jim  04  88.3% 

REASONS  WHY  THE  Ml  A2  DID  NOT  MEET  GOAL: 

REASONS  \UI\  THE  Ml  A2  DID  NOT  MEET  GOAL: 

1.  Ihe  RIDB  diia  loi  the  period  aiding  13  Apr  (4  shows  art  M 

1.  Ihc  RIDB  dila  lu  the  period  cinlmg  15  Juu  04  shows  an  M1A2  FMC  ot 

of  Hfi.KN  with  only  174  ichitk*  i  epurted  Ihe  5ACR  and  Ft  Knux  are 

88.3*  ■  with  only  268  vehicles  reported.  This  is.  an  iiinrcne  hum  the  Maythl 

the  only  unite  that  reported  Ml  A2s  fur  Apr  04.  The  following  unit 

FMC  uf  85.1%.  The  following  unite  missed  the  DA  goal 

tmssed  the  DA  goal: 

KNIT  OTA  FMC  NMCS  NMCM 

UNIT  Oil  FAR.  NMCS  NMCM 

3ACR  127  81%  7%  12% 

3ACR  12.1  83%  8%  7% 

Ft.  Knot  32  86%  6%  8% 

2  3  ACR :  The  3ACR  has  just  finished  its  tow  in  OFF.  and  m  currently 

2.  3  ACR :  The  3  ACR  has  just  finished  it*  tour  in  Q|E.  and  b  currently 

redeploy  ed  The  vehicle*  are  currently  in  Iranrat  from  overseas  No 

redeployed  The  vehicles  are  currently  in  transit  from  oswwas  The  majority 

sydemK  issue*  identified. 

o 4  downtime  is  attributed  to  nuintenance  ( 1 2%NMCMk  No  systemic  stuffy 
issues,  identified. 

RF  ADINF NS  f  Ml  \N<  EMKV1  . . Ns 

3  Ft.  Knox.  TRADOC:  The  MIA2s  at  Ft  Knox  showed  a  slight  decrease  in 

Near  -  J  crna  Fixe*: 

l.i.Ii  RAIN  Jiul 

-  Intense  Management  at  NMCS  requisitions 

.  tiiin.  ii.  ".  in.  h  i  ■!' :  l  V.l'i  *  .l.i.  >"  1 1 .  ii  in.  .uni*  for  deployment  lu 

•  Disassembly  piograms  in  place  lu  uhtAin  cnucal 

addition,  due  to  the  FAD i  Force  Activity  Designator!  code  this  unit  (.annul 

farts. 

order  item*  higher  than  a  "03”  priority  Unit  Maintenance  Activity  llTMA  1  is 
behind  on  service*  caumng  delays  in  repairing  vehicle* 

Emcnikil  Fixes 

>  Ramped  up  deliveries  on  critical  assemblies. 

-  RESEI  vehicle*  to  IU'2il  siandards. 

READINESS  ENHANCEMENT  ACTIONS: 

Near  •  Jems  Fixes: 

-  Intense  Management  of  NMCS  requisition* 

*  Disassembly  programs  in  place  tu  obtain  crilscal  parts. 

Extended  Fixes. 

-  Ramped  up  deliveries  on  critical  assemblies. 

*  RESET  vehicle*  to  III  21  •  standard*. 

Figure  9  RIDB  November  03,  February  04,  April  04  and  June  04  Summaries 


15 


2.  The  Equipment  Downtime  Analyzer  Reports 

The  Equipment  Downtime  Analyzer  (EDA)  Report  “provides  insight  through 
comparison  of  different  organizations  and  end  item  fleets.  It  can  help  answer  questions 
such  as: 

Is  this  fleet’s  readiness  problem  the  result  of  high  repair  time,  a  high 
failure  rate,  or  both? 

Is  an  organization’s  long  repair  time  driven  by  organizational  or  support 
level  repairs? 

How  much  does  parts  wait  time  contribute  to  repair  time? 

What  parts  are  contributing  the  most  to  lost  readiness? 

If  inventory  is  improved,  what  will  be  the  effect  on  equipment 
readiness?”(CASCOM) 

The  EDA  report  also  covers  a  monthly  period,  but  uses  a  calendar  month 
timeframe,  rather  than  the  URI  timeframe  of  the  16th  of  one  month  to  the  15th  of  the  next. 
It  provides  more  detail  than  the  RIDB  summary,  allowing  the  user  to  “drill  down”  within 
the  report  to  determine  just  how  long  a  specific  vehicle  was  considered  Non  Mission 
Capable  (NMC)  and  why.  However,  like  the  Operational  Readiness  Summary  Report  the 
EDA  report  only  goes  to  the  vehicle  level,  Figure  10  is  a  sample  top-level  report. 

The  Major  Command  has  the  capability  of  examining  logistic  reports  for  spare 
parts  ordered  and  generating  a  report  of  LRUs  that  are  failing  within  the  command. 
However,  occasionally  the  wrong  part  is  ordered  and  a  second  LRU  is  needed  to  correct 
the  problem.  This  means  that  looking  at  logistical  reports  of  parts  ordered  does  not 
necessarily  provide  an  accurate  picture  of  LRU  failure  trends. 
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III.  PROPOSED  ENHANCED  PROCESS 


The  GO/NOGO  approach  is  well  known,  has  been  in  use  for  a  long  time,  and  will 
continue  to  be  used.  The  information  generated  from  the  reports  in  Section  B  of  Chapter 
II  above,  tracks  to  the  vehicle  level.  This  needs  to  be  enhanced  to  be  more  proactive  in 
addressing  failures. 

A.  USE  CASE  ANALYSIS 

Use  Cases  are  valuable  because  they  allow  a  process  to  be  broken  down  into  an 
easily  understood  set  of  diagrams.  Use  Case  methodology  will  be  used  here  to  explain  the 
proposed  process.  “A  use  case  has  two  parts:  the  use  case  diagram  and  the  use  case  itself. 
The  diagram  provides  an  overview  of  which  interactions  will  be  important,  and  the  use 
case’s  text  details  the  requirements.”  (Daryl  Kulak  and  Eamonn  Guiney  2002) 

Use  cases  show  the  interaction  between  the  system  and  external  entities,  called 
Actors.  Figure  1 1  is  the  system  level  context  diagram  for  the  Master  Fault  Database.  For 
the  proposed  process,  there  is  one  system  called  the  Master  Fault  Database,  which 
interacts  with  several  Actors.  The  Actors  are  as  follows: 

•  The  Vehicle  Database,  from  which  the  majority  of  the  raw  data  is 
extracted. 

•  Users  at  the  vehicle’s  maintenance  facility  who  will  close  out  the  fault 
record  in  the  Database  once  the  LRU  has  been  repaired/replaced  and  the 
vehicle  declared  Mission  Capable.  (This  assumes  there  is  only  one  fault. 
When  multiple  faults  occur,  as  each  LRU  becomes  operational  within  the 
vehicle,  the  fault  will  be  considered  to  be  resolved.) 

•  Users  at  some  level  between  the  vehicle  and  the  Major  Command.  These 
actors  will  be  adding  additional  comments  such  as  why  the  vehicle’s 
Readiness  Report  is  overridden. 

•  Users  at  the  Major  Command  that  will  be  using  the  raw  data  to  generate 
reports  used  in  trend  analysis  and  for  logistics. 
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Figure  1 1  System  Level  Context  Use  Case  -  Master  Fault  Database 


There  are  four  use  cases  associated  with  this  system.  Because  the  number  of 
actors  interfacing  with  the  system  is  small  and  straightforward,  the  use  case  diagrams  are 
not  included.  Instead,  the  use  case  descriptions,  in  table  format,  are  provided  as  stand¬ 
alone  entities. 

1.  Fault  Data  Collection  Use  Case 

This  use  case  describes  the  process  of  recognizing  a  fault  and  collecting  related 
data.  It  also  describes  uploading  accumulated  data  to  the  Master  Fault  Database  and 
resetting  the  Vehicle  Database  to  free  up  precious  space  on  the  vehicle. 


Use  Case  Name:  Fault  Data  Collection 

Actors:  Tank  Crew,  Unit  Maintenance  Crew,  Vehicle  Database 

Summary:  When  a  fault  has  been  detected  in  a  vehicle,  related  data  is  collected.  During 
maintenance,  after  verifying  the  fault  is  repeatable,  the  fault  data  is  transferred  to  the 
Master  Fault  Database  and  the  Vehicle  Database  is  reset. 

Basic  Course  of  Events: 

1.  Vehicle  perfonns  self-test  and  detects  a  fault. 

2.  Vehicle  notifies  Tank  Crew  of  the  failure  and  stores  failure  information  in  the 
Vehicle  Database. 


20 


3.  Tank  Crew  runs  BIT  to  verify  the  fault  exists.  If  necessary,  Tank  Crew  adds 
comments  to  the  Vehicle  Database. 

4.  Vehicle  updates  the  Vehicle  Database. 

5.  Maintenance  Crew  will  re-run  BIT.  If  the  fault  is  repeatable,  they  will  run  FIT 
and,  if  necessary,  add  comments  to  the  Vehicle  Database. 

6.  Vehicle  will  update  the  Vehicle  Database  with  new  comments  and  add  TP  #  data. 

7.  Maintenance  Crew  transfers  data  from  the  Vehicle  Database  to  the  Master  Fault 
Database.  After  receiving  an  acknowledgement  from  the  Master  Fault  Database, 
the  vehicle  will  reset  the  Vehicle  Database. 

Alternative  Paths:  N/A 

Exception  Paths:  In  step  5,  if  the  problem  is  non-repeatable,  the  fault  record  will  be 
deleted  from  the  Vehicle  Database 

Trigger:  A  fault  is  recognized 

Assumptions:  The  vehicle  is  not  in  Combat  mode. 

Preconditions:  Vehicle  is  running 

Postconditions:  New  records  added  to  the  Master  Fault  Database;  Vehicle  Database  has 
been  reset 

Date:  20-Dec-04 

Table  3  Fault  Data  Collection  Use  Case 

2.  Override  Readiness  Index  Use  Case 

This  use  case  describes  when  a  User  in  the  Senior  Command,  above  the  Unit 
level,  has  overridden  the  Unit  Readiness  status  of  a  vehicle.  That  User  must  also  add  a 
comment  to  the  appropriate  record  in  the  Master  Fault  Database.  Note  that  even  though 
the  vehicle  is  considered  Mission  Capable,  the  fault  will  continue  to  exist  in  the  Master 
Fault  Database  until  someone  in  the  Unit  Maintenance  group  corrects  the  problem.  Only 
then  will  the  fault  be  closed. 
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Use  Case  Name:  Override  Readiness  Index 
Actors:  Senior  Command  Member 

Summary:  When  a  member  of  the  Senior  Command  wants  to  override  the  vehicle’s 
Operational  Readiness  status,  infonnation  identifying  the  User,  together  with  a  comment 
explaining  the  action  taken,  must  be  added  to  the  Master  Fault  Database. 

Basic  Course  of  Events: 

1 .  The  User  logs  on  to  the  Master  Fault  Database. 

2.  The  system  displays  a  list  of  options  to  the  User. 

3.  The  User  requests  access  to  a  vehicle’s  record. 

4.  The  system  displays  the  appropriate  record  and  prompts  for  additional 
information. 

5.  The  User  enters  requested  information,  including  a  comment  on  the  change  in 
Operational  Readiness  status. 

6.  The  System  updates  the  record  within  the  Master  Fault  Database. 

7.  The  User  logs  out  of  the  database. 

Alternative  Paths:  In  step  7,  if  the  user  wants  to  modify  another  vehicle’s  record,  steps  3 
through  6  are  repeated. 

Exception  Paths:  In  step  3,  if  the  User  enters  an  invalid  vehicle  identifier,  the  System 
displays  an  error  message  and  re-prompts  for  the  vehicle  identification.  The  User  may 
also  go  directly  to  step  7. 

Trigger:  The  User  requests  to  update  a  record  in  the  Master  Fault  Database 

Assumptions:  Someone  in  the  vehicle’s  chain  of  command  has  decided  the  vehicle  is 
Mission  Capable 

Preconditions:  A  Unit  Readiness  Report  has  been  received  indication  the  vehicle  is  NMC. 
Postconditions: 
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Table  4  Override  Readiness  Index  Use  Case 


3.  Report  Generator  Use  Case 

This  use  case  describes  when  a  User  in  the  Major  Command  requests  a  new 
report.  Reports  are  usually  run  on  a  scheduled  basis  but  may  also  be  run  on  an  exception 
basis.  Moreover,  reports  are  typically  run  at  the  Major  Command  but  may  be  run  by 
anyone  within  the  chain  of  command.  E.g.,  someone  in  Unit  Maintenance  might  request 
a  report  if  there  is  a  concern  about  similar  problems  with  other  vehicles. 


Use  Case  Name:  Report  Generator 

Actors:  Authorized  User  within  the  vehicles  chain  of  command  (up  to  the  Major 
Command  level) 

Summary:  A  User  requests  a  report  be  generated.  The  report  is  generated  using  data  from 
the  Master  Fault  Database 

Basic  Course  of  Events: 

1 .  User  logs  onto  the  Master  Fault  Database  and  requests  a  report. 

2.  System  displays  available  reports  for  that  specific  User 

3.  User  chooses  a  report. 

4.  System  processes  the  data  and  generates  the  report. 

5.  User  logs  out  of  the  database 

Alternative  Paths:  In  step  5,  when  additional  reports  are  requested,  steps  2  through  4  are 
repeated. 

Exception  Paths:  In  step  3,  if  the  User  is  not  authorized  to  request  a  specific  report,  step  2 
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is  repeated.  The  User  may  choose  to  go  to  step  5  if  desired. 

Trigger:  N/A 

Assumptions:  User  has  access  to  the  desired  reports. 

Preconditions:  User  has  logged  onto  the  Master  Fault  Database 
Postconditions:  Desired  reports  are  generated 
Date:  20-Dec-04 

Table  5  Report  Generator  Use  Case 

4.  Close  Vehicle  Fault  Use  Case 

This  use  case  describes  the  steps  taken  when  a  member  of  the  vehicle’s  unit 
maintenance  group  closes  a  fault.  Note  that  only  someone  from  the  Unit  Maintenance 
activity  has  authority  to  close  a  record.  That  will  prevent  accidental  closings,  which  in 
turn  would  cause  invalid  trend  analysis.  A  fault  may  be  closed  without  changing  the 
status  of  the  vehicle’s  Operation  Readiness.  This  may  occur  if  there  is  more  than  one 
fault  for  an  LRU,  or  if  the  vehicle  is  considered  NMC  because  multiple  LRUs  have 
failed.  The  vehicle  will  be  considered  Mission  Capable  when  all  faults  have  been  closed 
for  that  vehicle. 


Use  Case  Name:  Close  Vehicle  Fault 
Actors:  Unit  Maintenance  personnel 

Summary:  Someone  from  Unit  Maintenance  requests  a  vehicle’s  fault  record  in  the 
Master  Fault  Database  be  changed  to  closed  for  a  specified  fault 

Basic  Course  of  Events: 

1 .  A  User  logs  on  to  the  Master  Fault  Database. 

2.  The  system  displays  a  list  of  options. 

3.  The  User  chooses  to  close  a  fault  and  enters  the  appropriate  infonnation. 
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4.  The  system  updates  the  Master  Fault  Database. 

5.  The  User  logs  out  of  the  database. 

Alternative  Paths:  In  step  5,  if  the  User  wants  to  close  another  fault  record,  steps  3  and  4 
are  repeated. 

Exception  Paths:  If  the  User  is  not  authorized  to  close  a  fault  record,  the  system  will 
display  an  error  message  and  go  to  step  5. 

Trigger:  N/A 

Assumptions:  The  User  is  an  authorized  member  of  the  Unit  Maintenance  crew. 
Preconditions:  A  fault  has  been  corrected  in  a  vehicle. 

Postconditions:  The  Master  Fault  Database  has  closed  the  fault  record. 

Date:  20-Dec-04 

Table  6  Close  Vehicle  Fault  Use  Case 

B.  SEQUENCE  DIAGRAM 

Figure  12  is  a  sequence  diagram,  showing  the  interaction  between  the  different 
users  and  the  database.  Initially,  fault  data  captured  in  a  Vehicle  Database  will  be 
transferred  to  the  Master  Fault  Database.  Once  a  new  record  has  been  created,  an 
acknowledgement  will  be  sent  back  to  the  Vehicle  Database,  which  will  then  be  reset. 
There  is  limited  space  available  in  the  vehicle;  as  soon  as  possible,  old  data  must  be 
cleared  out.  At  the  same  time,  a  Unit  Readiness  Report  will  be  submitted  up  the  chain  of 
command.  At  some  level  above  the  unit,  a  user  in  a  Senior  Command  may  decide  to  add 
additional  information  into  the  Master  Fault  Database,  such  as  justification  for  overriding 
the  NMC  status  of  a  vehicle. 

Periodically,  users  at  the  Major  Command  level  will  run  reports  to  perform  trend 
analysis  and  to  view  a  more  accurate  Operational  Readiness  within  the  command. 
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Finally,  once  unit  maintenance  personnel  have  resolved  the  fault  (i.e.,  replaced  the 
hardware,  downloaded  a  new  version  of  software,  etc.),  the  fault  record  will  be  closed 
within  the  Master  Fault  Database. 


Figure  12  Master  Fault  Database  Sequence  Diagram 


C.  THE  PROPOSED  REPORTING  PROCESS 

New  reports,  tracking  failures  to  the  LRU  level  and  including  the  TP  #s  to  further 
isolate  the  faults,  will  be  added  to  the  current  process.  Several  steps  are  needed  to 
implement  this  enhancement  on  the  M1A2  Abrams.  A  similar  approach  would  be  used 
for  other  vehicles,  modifying  the  tenninology  for  the  Commander’s  display. 

•  A  vehicle  database  will  be  added  to  the  CID  LRU.  This  database  will  be  used 
for  collecting  the  Tank  Commander’s  comments.  It  will  also  gather  relevant 
information  for  each  of  the  warnings: 

•  Applicable  LRU  data  (hardware  serial  number;  software  version) 

•  Troubleshooting  Procedure  numbers  (TP#s),  used  to  describe  which  test 
procedure  failed. 
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•  A  check  will  be  performed  to  eliminate  duplicate  reports.  I.e.,  when  BIT 
and/or  FIT  are  run  after  ST  generates  a  warning,  only  one  set  of  data  will  be 
required.  Also,  if  the  vehicle  is  on  a  multi-day  exercise,  and  the  TC  decides  to 
continue  use  of  the  vehicle  until  the  exercise  is  complete,  the  same  error  might 
be  identified  over  several  days.  Only  one  occurrence  of  the  fault  should  be 
captured. 

•  The  process  for  undergoing  routine  scheduled  maintenance  will  be  modified 
to  include  gathering  fault-generated  data  stored  in  the  Vehicle  Database. 

•  Data  from  Vehicle  Databases  will  be  added  to  a  Master  Fault  database.  This 
master  database  will  be  owned  and  maintained  at  the  Major  Command,  but 
will  be  accessible  throughout  the  chain  of  command. 

•  Management,  up  the  chain  of  command,  will  incorporate  any  override  or  other 
comments  into  the  Master  Fault  database. 

•  Upon  request,  the  major  command  will  generate  trend  analysis  reports.  The 
results  of  this  analysis  will  be  forwarded  to  the  appropriate  logistics  group  for 
hardware  support  and  to  the  Software  Life  Cycle  Maintenance  group  for 
software  and  test  support. 

•  Units  below  the  Major  Command  can  also  generate  specific  reports.  These 
reports  will  be  useful  when  a  subordinate  unit  wants  to  perfonn  their  own 
trend  analysis. 

•  For  all  of  the  above,  proper  training  will  be  developed  and  implemented. 

Several  steps  must  be  taken  to  incorporate  these  databases. 

•  A  new  Vehicle  Database  will  be  added  to  the  vehicle’s  existing  software.  The 
physical  location  of  this  database  will  take  into  consideration  available  space 
for  the  new  code.  Some  LRUs  have  more  space  available  than  others.  If 
needed,  data  entered  will  be  passed  to  the  database  via  the  1553  data  bus  that 
connects  all  the  major  LRUs. 
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•  Screens  will  be  developed  within  the  vehicle  to  allow  data  entry.  The  screens 
will  be  added  to  the  CID  with  backup  capability  in  the  GCDP. 

•  When  a  fault  occurs,  the  TC  will  enter  pertinent  data  into  the  Vehicle 
Database.  This  will  include  whether  the  LRU  problem  is  addressed  at  that 
time  or  if  the  problem  is  overridden. 

•  A  Master  Fault  Database  for  all  of  the  vehicles  will  be  accessible  by  the  local 
maintenance  facility.  The  data  in  the  Vehicle  Database  for  each  vehicle  will 
be  transferred  to  the  Master  Fault  Database.  Data  from  other  Vehicle 
Databases  will  also  be  added  as  the  Master  Fault  Database  grows. 

•  Faults  are  identified  on  a  DA  Fonn  2404,  using  an  “X”  to  identify  the 
problem.  When  the  DA  Form  2404  has  a  fault  overridden  at  a  level  higher 
than  the  vehicle,  a  Circle-X  is  used.  As  this  occurs,  the  user  must  enter  a 
comment  into  the  Master  Fault  database  as  to  why  the  X  was  overridden. 

•  Data  from  the  Master  Fault  database  will  be  accessible  by  the  Program 
Manager’s  office  for  trend  analysis.  Assuming  a  failure  trend  is  identified, 
funding  will  be  requested  to  address  the  invalid  software/hardware/test 
software. 

•  Also  dependent  upon  the  trend  analysis,  an  adjustment  will  be  made  for  the 
number  of  spares  requested/needed. 
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IV.  MASTER  FAULT  DATABASE  DESIGN 


A.  OBJECT  DIAGRAM 

According  to  Martin  Fowler’s  book  on  UML,  “An  object  diagram  is  a  snapshot  of 
the  objects  in  a  system  at  a  point  in  time.”  (Martin  Fowler  and  Kendall  Scott,  2000).  The 
object  diagram  for  this  system  (shown  in  Figure  13)  will  consist  of  the  objects  described 
in  Table  7.  This  table  also  shows  the  relationships  (1  to  many,  many  to  many,  or  many  to 
1)  between  the  two  objects. 


Figure  13  Master  Fault  Database  Object  Diagram 


Object 

Relationship 

Object 

Description 

Report 

generalization 

Consists  of  four  (sample  report) 

objects:  Current  Status  Report; 

System  Version  Report;  TP  #  Report; 

and  LRU  Report. 

User 

generalization 

Consists  of  three  objects:  Unit 

Maintenance;  Major  Command;  and 

Senior  Command. 
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Report 

User 

One  or  more  users  can  generate  one 

or  more  reports. 

Vehicle 

1-* 

Current  Status 

Report 

One  or  more  vehicles  will  be 

described  in  the  Current  Status  report. 

Vehicle 

1-1 

Vehicle 

Database 

Data  for  each  (unique)  fault  is 

collected  in  that  vehicle’s  Vehicle 

Database. 

Vehicle 

Database 

1-* 

LRU 

The  Vehicle  Database  contains  an 

aggregate  of  data  for  the  faulty  LRU. 

LRU 

1-* 

Trouble¬ 

shooting 

Procedure 

Each  LRU  contains  an  aggregate  of 

one  or  more  TP  #s. 

Vehicle 

Database 

1-* 

System 

Version 

Report 

The  System  Version  Number  for  each 

vehicle  will  be  used  in  the  System 

Version  report. 

LRU 

*_* 

LRU  Report 

Data  from  many  LRUs  will  be  used 

in  the  LRU  Report. 

Troubleshooting 

Procedure 

TP  #  Report 

Data  from  many  TP  #s  will  be  used  in 

the  TP  #  Report. 

Vehicle 

Database 

*-l 

Master  Fault 

Database 

One  or  more  vehicles  will  provide 

data  to  the  Master  Fault  Database. 

Senior 

Command 

*_* 

Command 

Feedback 

One  or  more  members  of  the  Senior 

Command  provide  input  to  the 

Command  Feedback  object. 
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Command 

Feedback 

*-l 

Master  Fault 

Database 

One  or  more  Command  Feedback 

sets  provide  updated  data  to  the 

Master  Fault  Database  for  each  fault 

in  the  database. 

Unit 

*_* 

Master  Fault 

One  or  more  Unit  Maintenance 

Maintenance 

Database 

personnel  close  one  or  more  faults 

when  the  faults  are  resolved. 

Table  7  Object  Relationships 


B.  DATABASE  DESIGN 

1.  Database  Contents 

The  Master  Fault  Database  will  contain  information  collected  from  the  Vehicle 
Databases  throughout  the  command  as  well  as  information  entered  by  the  various  levels 
between  the  Major  Command  and  the  Vehicle  level.  Table  8  identifies  the  data,  where  it 
is  derived  from,  and  why  it  is  included  in  the  database. 


Data 

Source 

Comment 

Vehicle  System  Software 

Version 

From  the  CID  LRU 

(Vehicle  Database) 

Used  for  trend  analysis 

LRU  ID 

From  in  the  CID  LRU 

(Vehicle  Database) 

Used  for  trend  analysis 

TP# 

From  the  CID  LRU 

(Vehicle  Database) 

Used  for  trend  analysis 

Vehicle  ID 

Entered  by  the  TC 

(Vehicle  Database) 

Unique  value,  used  as  the  Primary 

Key. 

Date/Time 

Entered  by  the  TC 

(Vehicle  Database) 

Used  to  determine  how  long  the 

vehicle  was  NMC. 

Vehicle  Operational 

Entered  by  the  TC 

Used  for  trend  analysis,  and  to 
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Data 

Source 

Comment 

Readiness  Index 

Override? 

(Vehicle  Database) 

detennine  actual  operational 

readiness. 

Reason  for  Override 

Entered  by  the  TC 

(Vehicle  Database) 

Used  for  trend  analysis,  and  to 

detennine  actual  operational 

readiness. 

Additional  comments 

Entered  by  the  TC 

(Vehicle  Database) 

Used  by  maintenance,  for  reasons 

for  failures,  and  by  logistics 

personnel  when  ordering  spares. 

Vehicle  Operational 

Readiness  Index  Override 

Senior  Command 

personnel 

Corresponds  to  a  circle-X.  Used  to 

detennine  actual  operational 

readiness 

Reason  for  Override 

Senior  Command 

personnel 

Used  to  determine  actual 

operational  readiness 

Date/Time  of  Override 

Senior  Command 

personnel 

Used  to  determine  actual 

operational  readiness 

Overriding  Authority 

Identification 

Senior  Command 

personnel 

Used  to  determine  actual 

operational  readiness 

Additional  Comments 

Senior  Command 

personnel 

Used  to  determine  actual 

operational  readiness 

Table  8  Master  Fault  Database  Contents 


2.  Sample  Database  Layout 

Records  within  the  Master  Fault  Database  consist  of  fields  containing  data 
transferred  from  the  individual  Vehicle  Databases  and  additional  fields  containing  data 
from  senior  commands  over  the  reporting  vehicles.  In  keeping  with  best  practices  for 
database  design,  the  data  will  be  divided  into  several  tables  to  minimize  the  possibility  of 
data  corruption,  keep  the  database  more  manageable,  and  speed  processing. 


32 


The  primary  key  for  each  table  will  be  the  vehicle  ID.  Data  for  a  fault  will 
initially  be  transferred  from  the  applicable  vehicle.  Additional  infonnation  may  be  added 
by  commands  above  the  vehicle  level  in  the  chain  of  command.  Maintenance  personnel 
may  indicate  the  fault  has  been  corrected  and,  depending  upon  if  other  faults  exist, 
whether  the  vehicle  is  now  Fully  Mission  Capable. 

Figure  14  is  the  Entity  Relationship  Diagram  for  the  Master  Fault  Database. 
There  may  be  one  or  more  failures  occurring  within  a  vehicle,  so  the  diagram  shows 
multiple  failures  submitted  to  the  Master  Fault  Database.  It  also  shows  personnel  in  the 
chain  of  command  above  the  reporting  unit  may  update  information  on  each  fault  one  or 
more  times.  I.e.,  infonnation  may  be  submitted  by  someone  at  the  Company  level,  and 
also  by  someone  at  the  Battalion  level. 


Vehicle 

M 

Report'\. 

M 

Master 

Vehicle 

Database 

M 

Update\ 

M 

Subordinate 

Database 

^xFailure/^ 

\Failure/^ 

Command 

Figure  14  Entity  Relationship  -  Master  Fault  Database 


There  are  two  tables  containing  data  for  the  Master  Fault  Database,  as 
described  below.  Each  field  of  both  Table  9  and  Table  10  identify  the  database  Primary 
Key,  Field  name,  type,  size,  whether  it  is  a  required  field,  and  a  comment  field  to  explain 
where  the  data  is  derived. 

a)  Vehicle  Data  Table 

Table  9  contains  data  extracted  from  the  Vehicle  Database.  It  allows  for 
up  to  six  Troubleshooting  Procedure  numbers.  Each  failure  within  a  vehicle  will  have  its 
own  record  within  the  database  which  will  allow  individual  faults  to  be  closed  while  still 
allowing  the  vehicle  to  be  classified  NMC  due  to  any  other  outstanding  fault  records. 
This  will  also  allow  a  more  accurate  trend  analysis  to  be  performed  on  individual  faults, 
rather  than  just  on  vehicles. 
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Key 

Field 

Type 

Size 

Req’d 

Field 

Comments 

P 

Vehicle  ID 

A/N 

20  Chars 

Y 

Captured  from  the  CID  LRU 

Key  types  are  Primary, 

Secondary,  Foreign 

System  Version 

A/N 

10  Chars 

Y 

Captured  from  the  CID  LRU 

LRU 

A/N 

7  Chars 

Y 

Captured  from  the  CID  LRU 

LRU  S/W  Vers. 

A/N 

7  Chars 

Y 

Captured  from  the  LRU 

LRU  H/W  Ser.  # 

A/N 

7  Chars 

Y 

Entered  by  User  (Tank  Crew, 

Maintenance  personnel) 

TP# 

N 

5  Chars 

Y 

Captured  from  the  CID  LRU 

TP# 

N 

5  Chars 

Y 

Captured  from  the  CID  LRU 

TP# 

N 

5  Chars 

Y 

Captured  from  the  CID  LRU 

TP# 

N 

5  Chars 

Y 

Captured  from  the  CID  LRU 

TP# 

N 

5  Chars 

Y 

Captured  from  the  CID  LRU 

TP# 

N 

5  Chars 

Y 

Captured  from  the  CID  LRU 

Date/Time 

A/N 

20  Chars 

Y 

Entered  by  User 

Comment 

A/N 

240  Chars 

Y 

Entered  by  User 

Table  9  Vehicle  Data  -  Master  Fault  Database 


b)  Change  in  Status  Table 

Table  10  will  contain  data  entered  by  members  of  commands  senior  to  the 
faulted  vehicle.  Data  may  be  entered  when  overriding  a  circle-x  or  just  in  general  to 
explain  a  failure.  It  may  also  be  submitted  to  assist  the  Major  Command  when  generating 
a  trend  analysis  report. 
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Key 

Field 

Type 

Size 

Req’d 

Field 

Comments 

P 

Vehicle  ID 

A/N 

20  Chars 

Y 

Captured  from  the  Vehicle’s 

Form  2404 

LRU 

A/N 

7  Chars 

Y 

Captured  from  the  Vehicle’s 

Form  2404 

User  Name 

A/N 

20  Chars 

Y 

Entered  by  User 

UnitID 

A/N 

20  Chars 

Y 

Entered  by  User.  Name  of 

user’s  Unit 

Change  Status 

A/M 

5  Chars 

O 

Entered  by  User 

Date/Time 

A/N 

20  Chars 

Y 

Entered  by  User 

Comment 

A/N 

240  Chars 

Y 

Entered  by  User 

Table  10  Change  in  Status  -  Master  Fault  Database 


3.  Sample  Database  Reports 

Some  of  the  reports  that  can  be  generated  from  this  database  are: 

Current  Status  of  Fielded  Vehicles  -  indicates  the  status  of  fielded  vehicles  within 
a  specified  command.  By  varying  the  report  date,  the  command  can  determine  trends.  It 
also  shows  a  more  accurate  Operational  Readiness  Status. 

Failure  Analysis  By  LRU  -  indicates  if  there  is  a  fundamental  problem  emerging 
for  a  specified  LRU.  It  will  also  help  ensure  the  proper  numbers  of  spares  are  ordered. 

Failure  Analysis  by  Troubleshooting  Procedures  -  this  report  will  isolate  failures 
by  software  or  hardware  categories.  It  should  be  used  in  conjunction  with  the  Failure 
Analysis  by  LRU  report  when  ordering  spares.  For  example,  if  there  are  hardware  issues, 
then  replacements  are  needed.  But  if  the  TP  #s  indicate  the  issues  are  software  related, 
then  updated  software  should  be  developed/installed. 
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Failure  Analysis  by  System  Versions  -  this  will  identify  if  issues  are  being 
introduced  or  resolved  by  different  versions  of  system  releases.  This  report  should  be 
used  in  conjunction  with  the  other  failure  analysis  reports.  Failures  introduced  by  new 
versions  of  hardware  or  of  software  need  to  be  analyzed  as  a  whole  rather  than 
individually. 

For  the  following  sample  reports,  the  Fourth  Infantry  Division  is  (arbitrarily) 
used.  The  reports  are  as  follows: 

a)  Current  Status  of  Fielded  Vehicles 

This  sample  report  (Figure  15)  examines  vehicles  assigned  to  the  4th  ID. 
For  each  NMC  vehicle,  the  vehicle  identification  is  displayed  together  with  the  date  the 
vehicle  became  NMC.  This  infonnation  allows  the  Major  Command  to  take  action  as 
appropriate:  move  vehicles  from  one  unit  to  another,  check  on  status  of  spares,  determine 
if  command  assistance  is  required  to  resolve  delays,  etc. 


Current  Status  of  Fielded  Vehicles 

Command: 

4ID 

1st  Brigade.  4th  Infantry 

1-66  Armor  Bn  Total  Number  of  Vehicles  On  Hand:  XXX 

Disabled  Vehicles:  XXX 

Vehicle  ID:  XXXXXXXXX  Disabled  since:  XX’XXXX 

3-66  Armor  Bn  Total  Number  of  Vehicles  On  Hand:  XXX 

Disabled  Vehicles:  XXX 

Vehicle  ID:  XXXXXXXXX  Disabled  since:  XXXXXX 
Vehicle  ID:  XXXXXXXXX  Disabled  since:  XX  XX  XX 

2nd  Brigade,  4th  Infantry 

I  -67  Armor  Bn  Total  Number  of  Vehicles  On  Hand:  XXX 

Disabled  Vehicles:  XXX 

Vehicle  ID:  XXXXXXXXX  Disabled  since:  XX  XX  XX 
Vehicle  ID:  XXXXXXXXX  Disabled  since:  XX  XX  XX 
Vehicle  ID:  XXXXXXXXX  Disabled  since:  XXXX  XX 

3-67  Armor  Bn  Total  Number  of  Vehicles  On  Hand:  XXX 

Disabled  Vehicles:  XXX 

Vehicle  ID:  XXXXXXXXX  Disabled  since:  XX  XX  XX 
3rd  Brigade.  4th  Infantry 

1-68  Armor  Bn  Total  Number  of  Vehicles  On  Hand:  XXX 

Disabled  Vehicles:  XXX 

Vehicle  ID:  XXXXXXXXX  Disabled  since:  XX  XX  XX 


Figure  15  Sample  Current  Status  of  Fielded  Vehicles  Report 


Dale: 

XXXXXX 
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b)  Failure  Analysis  by  LR  U 

This  sample  report  (Figure  16)  shows  the  number  of  LRU  failures  for  each 
vehicle  within  a  Major  Command.  The  report  further  identifies  the  individual  vehicles 
and  shows  the  number  of  days  the  LRU,  and  in  turn,  the  vehicle,  is  considered  NMC. 


LRU  Failure  Analysis  Report 


Command: 

4ID 

LRU 

CID 

Veh  ID 

Vets  fl 

XXXXXX 

xx.xx 

CITY 

xxxxxx 

xx.xx 

xxxxxx 

xx.xx 

xxxxxx 

XX  XX 

DECU 

xxxxxx 

xx.xx 

DID 

GCDP 

xxxxxx 

xx.xx 

FCEU 

xxxxxx 

xx.xx 

IIEU 

IFCEU 

xxxxxx 

xx.xx 

POS/NAV 

TEU 

xxxxxx 

xx.xx 

Date: 

xxxxxx 


Dale  Failed 

Total  Days 

XXXXXX 

XXX 

xxxxxx 

XXX 

xxxxxx 

XXX 

xxxxxx 

XXX 

xxxxxx 

XXX 

xxxxxx 

XXX 

xxxxxx 

XXX 

xxxxxx 

XXX 

xxxxxx 

XXX 

Figure  16  Sample  LRU  Failure  Analysis  Report 


c)  Failure  Analysis  by  Troubleshooting  Procedures 
The  following  sample  report  (Figure  17)  shows  the  number  of  failures  by 
troubleshooting  procedure  number  for  each  vehicle  within  a  Major  Command.  The 
report  further  identifies  related  TP  #  failures  and  shows,  for  the  specific  failure,  the  date 
the  failure  occurred.  This  date  is  not  necessarily  the  date  the  vehicle  is  considered  NMC 
since  the  vehicle  may  have  been  rated  NMC  prior  to  identifying  the  failed  TP  #.  I.e., 
there  might  be  a  failure  in  an  LRU  and,  after  replacement  of  the  LRU,  the  FIT  identified 
a  second  LRU  problem. 
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Troubleshooting  Procedures  Failure  Analysis  Report 


Command: 

4ID 

TP#  Veh  ID  Related  TP 

NNN  XXXXXX  NNN 

NNN  XXXXXX 

NNN  XXXXXX  NNN 

Related  TP 
NNN 

NNN 

Related  TP 

NNN 

Dale: 

XXXXXX 

Date  Failed 
XXXX  XX 
XXXX  XX 
XXXXXX 

Total  failures  for  TP  #  NNN: 

NNN 

NNN 

XXXXXX 

XXXXXX 

Total  failures  for  TP  #  NNN: 

NNN 

NNN 

XXXXXX 

XXXXXX 

NNN 

XXXXXX  NNN 

NNN 

NNN 

XXXXXX 

Total  failures  for  TP  #  NNN: 

NNN 

Figure  17  Sample  TP  Failure  Report 


d)  Failure  Analysis  by  System  Versions 

The  following  sample  report  (Figure  18)  shows  failures  that  occur  within  a 
vehicle  loaded  with  a  specific  system  drop  of  software.  When  compared  to  the  previous 
system  drop,  it  will  help  to  identify  which  software  failures  were  resolved  and  which 
were  introduced.  The  latter  may  occur  when  a  problem  is  masked  due  to  another 
problem.  Once  that  other  problem  is  resolved,  the  second  problem  can  be  identified  and 
resolved.  The  report  will  contain  entries  for  all  system  drops  currently  fielded. 


Command:  41D 


System  Drop  Failure  Analysis  Report 

Date:  XX/XX/XX 


System  Version  Number:  XXX. XXX 


LRU 

NNN 

LRU  Vers 
XXX.XXX 
XXXXXX 
XXX.XXX 

Veh  ID 
XXXXXX 
XXXXXX 
XXXXXX 

Date  Failed 

xx/xx/xx 

xx/xx/xx 

xx/xx/xx 

Total  Days 
NNN 
NNN 
NNN 

NNN 

XXXXXX 
XXX  XXX 

XXXXXX 

XXXXXX 

xx/xx/xx 

xx/xx/xx 

NNN 

NNN 

System  Version  Number:  XXX.XXX 

LRU 

NNN 

LRU  Vers 
XXXXXX 
XXX.XXX 
XXXXXX 

Veh  ID 
XXXXXX 
XXXXXX 
XXXXXX 

Date  Failed 

xx/xx/xx 

xx/xx/xx 

xx/xx/xx 

Total  Davs 
NNN 
NNN 
NNN 

NNN 

XXXXXX 

XXXXXX 

xx/xx/xx 

NNN 

NNN 

XXXXXX 

XXXXXX 

XXXXXX 

XXXXXX 

xx/xx/xx 

xx/xx/xx 

NNN 

NNN 

Figure  18  Sample  Failure  Analysis  by  System  Versions 
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V.  CONCLUSION 


The  enhancements  proposed  in  this  thesis  have  been  recognized  by  the  Associate 
Director  of  the  Next  Generation  (NextGen)  Software  Engineering  Center,  RDECOM  - 
TARDEC  for  their  potential  to  quantify  and  resolve  low-level  software  and  hardware 
issues.  This  concept  has  been  submitted  as  a  proposal  to  become  a  Department  of 
Defense  Small  Business  Innovation  Research  (SBIR)  Program. 

A.  VALUE  ADDED 

Current  reports  can  identify  a  vehicle  classified  as  NMC.  They  cannot  further 
identify  the  LRU  that  is  the  cause  of  the  failure.  That  information  might  be  available 
from  examining  logistical  spare  parts  orders  for  the  unit  but  if  the  wrong  LRU  is  ordered, 
that  information  is  not  accurate  either.  This  is  somewhat  trial  and  error,  and  prevents  any 
accurate  trend  analysis  from  being  performed  at  the  major  command  level.  Also, 
historical  data  for  operational  readiness  is  not  being  maintained.  That  means  the  Major 
Command  may  review  the  current  status  of  its  vehicles,  only. 

Having  the  additional  information  contained  in  the  Master  Fault  Database  will 
allow  statistical  trends  to  be  reviewed  and  will  allow  commanders  to  maintain  better 
control  when  ordering  replacement  LRUs. 

Implementing  the  new  database  systems  will  continue  to  allow  Tank  Commanders 
(TCs)  and  their  chain  of  command  to  use  their  best  judgment  on  the  operational  readiness 
of  a  vehicle.  At  the  same  time,  it  will  enable  them  to  capture  important  information  that 
will  improve  the  state  of  their  repair  parts,  and  ultimately,  improve  the  quality  of  the 
vehicle’s  hardware  and  application  and  test  software. 

B.  CHALLENGES  AND  OPPORTUNITIES 

1.  Safety  Critical 

System  Safety  is  always  a  major  concern.  From  a  top-level  view,  a  major 
command  expects  its  units  to  be  combat  ready  based  on  the  URI  for  each  unit.  With 
more  detailed  reports  available,  the  chain  of  command  can  better  manage  their  units  in 
preparation  for  their  primary  duty  —  to  engage  the  enemy. 
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From  the  unit’s  viewpoint,  resolving  problems  with  faulty  LRUs  and  having 
sufficient  numbers  of  spares  available  is  certainly  optimal. 

Addressing  reasons  for  failure,  situations  where  the  test  might  be  masking  more 
serious  problems,  will  hopefully  save  crewmembers’  lives. 

2.  Difficulty  in  Gaining  Acceptance 

During  an  interview  with  a  former  Tank  Commander,  SFC  Tom  Davis,  retired, 
SFC  Davis  said  the  majority  of  all  faults  are  documented  on  a  daily  basis,  on  the 
vehicle’s  DA  Form  2404  (Equipment  Inspection  and  Maintenance  Worksheet).  It  is  in 
the  best  interest  of  the  vehicle’s  crew  to  ensure  that  the  vehicle  is  fully  operational  at  all 
times.  Crewmembers  want  to  see  all  faults  identified  and  corrected,  and  an  appropriate 
level  of  spares  maintained.  It  is  their  livelihood  and  their  lives  at  stake.  The  problem  of 
overriding  the  readiness  status  appears  to  be  at  the  company  and/or  battalion  level.  That 
is  where  the  Circle-X’s  are  being  used.  The  challenge  then  is  to  allow  personnel  at  those 
levels  to  override  the  report  while  getting  them  to  provide  explanations. 

This  challenge  can  be  addressed  by  reporting  the  additional  information  at  the  top 
level  of  the  chain  of  command  and  then  have  that  report  flow  back  down  the  chain.  Once 
management  at  the  lower  levels  observes  that  upper-management  is  viewing  this 
information  in  the  new  reports,  there  will  hopefully  be  a  better  flow  of  communication  at 
all  levels. 

SFC  Davis  identified  a  second  challenge:  crewmembers  are  constantly  busy  with 
the  current  amount  of  daily  requirements.  He  suggests  that  there  may  be  resistance  to  the 
process  caused  by  adding  another  requirement,  to  enter  the  reason  for  the  fault  into  the 
database,  to  their  workload.  Once  they  see  an  increase  in  the  attention  spent  on 
improving  the  operational  readiness  of  the  vehicles,  this  resistance  should  be  overcome. 

3.  Incorporation  on  Legacy  Vehicles 

Because  of  budget  constraints,  incorporating  this  process  into  legacy  systems  may 
prove  to  be  the  greatest  challenge.  The  Program  Executive  Office  for  the  legacy  vehicle 
will  need  to  add  the  development  of  the  database  software;  training  for  the  new  system; 
new  processes  developed  for  perfonning  trend  analysis;  etc.  into  the  vehicle’s  budget. 
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Since  the  majority  of  available  funding  is  already  designated,  this  process  will  need  buy- 
off  at  all  levels. 

4.  Incorporation  on  Future  Force  Vehicles 

Since  there  hasn’t  been  any  precedence  set  for  the  new  vehicle,  incorporating 
these  new  processes  should  be  much  easier.  The  additional  features  outlined  by  this 
research  as  essential  for  improving  the  current  Unit  Readiness  Index  reporting  procedures 
can  be  incorporated  into  initial  system  design.  Features  such  as  automatically  recording 
data  into  the  vehicle  database,  and  automatically  modifying  the  number  of  spares 
required  by  command  (based  on  an  automated  specific  trend  analysis  to  gauge  projected 
failures  based  on  the  number  of  current  and  previously  reported  failures)  can  be  built  in 
and  prevent  the  continuation  of  the  current  Operational  Readiness  reporting  problem. 
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